In conventional computing environments, the only means available to invoke the execution of commands, in sequence, upon a target system require that at least one of the following be installed on the target system: 1) a platform-specific (i.e., native) binary executables on the target system, 2) scripts and matching scripting language interpreters (e.g., PERL, PYTHON, Windows BAT Files plus their respective interpreters), or 3) a virtual machine interpreter and/or a “just in time” (JIT) compiler and matching virtual machine executables (e.g., a Java virtual machine (VM)). All of these methods require that the target system support the installation of compilation and/or interpretive software, and further requires the storage of scripts and other executables prior to their use on the target system. These requirement necessitate that additional software be installed on the target system, at a cost expressed in terms of target system resources consumed (i.e., storage space), the time required, by person or by automation, to conduct and validate the installation of the software, and the cost of maintaining the software after installation (i.e., providing patches, software repair, software replacement, and/or software removal).
In addition, conventional systems require the means to provide support for the installation and configuration of software on each of the target systems maintained in the computing environment. Furthermore, access credentials sufficient to support the installation and configuration of the software must be provided and managed.
Another drawback of conventional systems wherein the software is maintained on the one or more target systems is that such software, once installed, must be granted privileges sufficient to carry out its intended tasks. As such, the software must be free of any intentional or accidental compromises which may impede or disrupt the intended use of the target system.
Moreover, conventional systems and methods place a significant burden on the system administrator to assemble and have available the technical skills necessary to craft scripts, binary executables, and/or virtual machine programs specific to each target system to be managed and/or monitored. This generally requires the administrator to hire staff or consultants to author the required code or acquire the required code or files from a third party.
Traditionally, there are four principal architectures by which one or more target systems receive requests for command execution from a central managing system. The first architecture involves processing the request using specific protocols (e.g., SNMP), in which a standard agent (i.e., the target system) exposes control functionality and target system data to the managing system. According to this architecture, the software enabling the support of a such a protocol must be installed and configured on the target system in support of this capability, or enabled if already installed, and secured against unauthorized access requests.
A second common architecture, referred to as a “service” model, involves the use of a target system thread of execution (such as, for example, a daemon process on Linux systems or a Service on Windows systems), which responds to requests made of it by the managing system.
A third general architecture, referred to as an “agent” model, involves the use of a communications protocol (such as Telnet, SSH, FTP, or one of proprietary design) by the managing system, to invoke the execution of scripts or executables previously loaded or installed on the target system, whose resultant data is optionally captured by the managing system. An agent, or agent system, is defined as a system having installed thereon software specifically adapted for the purpose of monitoring that system. Generally, the monitoring software on the agent system includes a schedule of actions to be taken and sequences of commands to be executed.
At a high level, these individual commands have no state or state information. However, individual commands may be logically associated and strung together in a command sequence. As such, the results of the individual commands that make up a command sequence may be considered together to inform and/or direct future processing by a system (e.g., data collection, parsing, storage, communications, etc.). In order to perform an action which is conditioned on the results of a plurality of individual commands requires the management of the state of the command sequence. The command results and state of the command sequence executions are stored on the agent system, pending delivery of the results to a managing system.
However, each of the above-described architectures disadvantageously require that software and/or command scripts be installed on the target system. Further, the software and/or scripts must be executed on the target system, and require the use of significant processing resources. Additionally, such software and/or scripts must be maintained, irrespective of whether or not the installation is permanent (i.e., in the event the target system has mass storage) or loaded upon reboot (i.e., in the event the target system is “diskless”). Moreover, IT organizations consider the enabling of generalized command and control protocols (such as SNMP) on a target system as a security risk.
A fourth architecture, referred to as an “agentless” model, involves the use of a communications protocol (such as, for example, Telnet, SSH, or FTP) by the managing system, to invoke the execution of a specific and singular command on the target system, whose resultant data is optionally captured by the managing system. According to this model, no software is installed on the target system for the purpose of monitoring that system. However, such software is forwarded to that system and executed upon demand. Because this software is not ‘permanently’ stored on the agentless target system, it is not able to survive a reboot. However, once a command sequence is provided to such agentless target system, all instructions of the command sequence are executed, with the state of such execution managed and maintained by the agentless target system. Furthermore, the results are passed back to the managing system, as there are no provisions for the storage of the results on the agentless target system.
However, the conventional agentless model is able to execute only individual commands on the target system, and not command sequences. As such, the traditional agentless model does not support conditional execution of commands on the target system.
Consequently, there is a need in the art for a system and method for efficiently and effectively managing one or more target systems using a managing system.